I was an expert at ColdFusion. A couple of the guys who I remember racing for "the right answer" are still up there, including one who came after the guys who came after the guys who came after Dain "OMFG do they really have a book on ACM?" Anderson. You might know him. It might be from cfcomet fame.

(I have no clue why my email address from back then says I have no account, nor do I know why I'm no longer listed in the top experts even though I ha(d/ve) the points).

I used to give EE ideas on how to make their service better. I don't mean to sound like an ideaman -- I know ideas are only worth something when they're executed -- but I told them I'd implement the ideas for them. A simple one that I harped on was: instead of getting X number of email notifications on a question, send me the first one, and only send me subsequent emails if I've logged in.

This was before RSS days, so I had no way to stay up-to-date without it (or shittons of irrelevant emails). It wasn't a hard thing to implement. It didn't matter though: my suggestions fell on deaf ears. And the site, as you know, tried to maximize earnings while ensuring it's audience remained pissedoffandalienated.

That's right, when I stopped contributing, EE became an outhouse on the web. I take full credit: when I left, EE began its downfall.

Seeing as you're reading this blog, chances are that you're a programmer. Being such, you probably know how evil ExpertS-exchange became. You (used to) google for a problem, and more often that not, some spammy BS from that site would show up. If you were savvy and in-the-know, you'd not have clicked on it. And if you didn't happen to be paying attention, you'd realize you made that gawdawful click when you saw the page loading, and immediately scroll to the bottom to see the answer.

It was ripe for ripping and easy to pick off. That's a 20-20 hindsight thought. StackOverflow is in the process of taking over EE (if it hasn't by the time you read this). Thankfully.

But the two programmers' questions websites are incidental to this story. Actually, this story is more about business, and recognizing a market and capitalizing on it.

A little while ago, I was looking for content to embed in a high-school course. I thought,



It's still true. But then, at the time of this writing, I was looking for the non-clipboard-screenshot-save-as-file keyboard shortcut on MacOSX.



It looks like a pattern. But it's not yet.





Even though I already play guitar, I was wondering about how I might teach it to my daughter. I was self-taught, so I don't know how I'd go about teaching someone else without feeling like I've crippled them. Later, after spending the evening with teachers and principals, I was thinking about how they accommodate gifted kids.

As you can tell, it doesn't matter what I think. It doesn't matter what you think. About.com comes up in all these (seemingly?) random cases as an authority answer to the question. What's worse: it's hard enough to tell the ads from the content for someone you'd expect to be savvy on that. Can you imagine the hardship a "normal person" would suffer?



If it's not obvious now, the million dollar idea is to do to About.com what StackOverflow did to Experts-Exchange. I assume About.com has some good content, but it's too hard to tell by looking at it. The position is ripe for the picking. Create an unspamalicious About.com and you're rich.

Tell me about it if you make the attempt. I'll link it here.

Requirements

1. Can you name a number of non-functional (or quality) requirements?
   I'd first mention performance and security, from the user's perspective. I'd then mention meeting minimum requirements for metrics like code coverage in testing and dependencies in our design. I don't consider code quality out-of-order when it comes to requirements.
   
   The non-functional requirements page at Wikipedia lists several examples. Notable exceptions from my quickie-response: accessibility, documentation, portability. There are several that are listed that I consider covered by what I've listed, but I missed some that caused me to say
   
   
   
   
2. What is your advice when a customer wants high performance, high usability and high security?
   My "advice" starts with the questions: "What do you consider X to be?" where X belongs to the set {"high performance", "high usability", "high security"}. I might offer that I consider "high performance" to be a misnomer, as it's either acceptable or not, and that unless the customer defines it, I don't know how we'd even attempt to measure something as vague as "usability."
   
   I'm not sure where I'd prepare for this question. Any suggestions are appreciated.
   
   
3. Can you name a number of different techniques for specifying requirements? What works best in which case?
   I can name several: tell me in person, tell me over email, tell me over IM or over the phone. I know that's not what you're looking for. You're looking for answers like "use cases." It all boils down to the same. I might even mention "unit tests" here. That's part of the spec, as far as I'm concerned, and for almost any software I write for myself, it's the only way I specify requirements (except for maybe a very informal to-do list).
   
   Face-to-face works best in most cases, I'd gather.
   
   The answer after doing some research: ¡Ay, ay, ay, no me gusta! I didn't see this coming. There are a number of things that could qualify as answers (Prototyping, Storyboards, Modeling, ..., State transitions) that I knew about beforehand. I thought to include none of them.
   
   
   
   
4. What is requirements tracing? What is backward tracing vs. forward tracing?
   My response? "I don't know anything about requirements tracing. I'm willing to learn."
   
   Once again, Wikipedia tells us about requirements traceability, illuminating the issue for us.
   
   
5. Which tools do you like to use for keeping track of requirements?
   I generally use a combination of a text file and emails, as far as the client is concerned. If it's a larger system, I'll use something like Sharepoint, Basecamp, or another system that performs a similar function. I have no preferences, because nothing I've ever used compares to a simple list. If it does, it's equally useful.
   
   I don't know that I'd say I like any of them. In reality I prefer a simple to-do list that I encode in tests (insofar as I'm capable of writing the tests) and knock them out one-by-one.
   
   
6. How do you treat changing requirements? Are they good or bad? Why?
   I don't give a value judgement on changing requirements: they are inevitable. They can be good or bad depending on how the client handles them.
   
   I always try to let the client know: I can do X amount in Y timeframe. You asked for Z total. Here's an estimate for each item in Z, pick X from it for our current Y timeframe. I'll get back to you every Y timeframe to show a demo, and you can choose X from the remaining Z again (with changes based on circumstances if required). Feel free to fire me when you have enough out of Z that's functional. (Ok, I probably wouldn't say the last sentence in those terms, but I'd find a way to say it, if for no other reason than to sell them the rest of the process.)
   
   As far as looking it up before the interview: I've review Agile literature. Searching any of the agile yahoo groups for the question at hand ought to be good enough.
   
   
7. How do you search and find requirements? What are possible sources?
   "What do you mean?" would be my response. I really don't know. What does searching and finding requirements mean? Does it mean figuring out how to do requirements that I don't know how to accomplish?
   
   If so, the first step is Google. In the rare event no one that I can find has had my problem, I'll go traipsing through the source code if it's available.
   
   Clearly, I don't know where to start here.
   
   
8. How do you prioritize requirements? Do you know different techniques?
   I rarely prioritize requirements. I let the customer decide. I give them a relative cost of implementing X requirement vs. implementing Y requirement, and let them decide. If Y requires X, then I tell them so.
   
   I know of different techniques - take "random" for example. I don't know what they might be called. But I cannot think of anything better, even if it were decreed as a Top 10 Commandment for Prioritizing Requirements.
   
   No web search for this comes to mind. I'd review a couple of process management books if I had no clue. This seems to be a decent discussion, if you must have one from me from a cursory browse.
   
   
9. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
   The user will be the person using the software, versus the customer being the one who pays for its development. I hate that distinction. The developer programs it. Responsibilities? In my ideal organization, I'd have:
   • Developers working with the Customer to manage requirements.
   • Developers working with the User to make the application work for them regardless of the Customer (I've seen too many projects where the User had to use whatever the Customer purchased, even if the purchase was ... little yellow bus-ish.)
   • Customer/User having daily meetings with the developer
   • Developer making the best software he/she can given the constraints.
   Again, I don't know where I'd look this up before being asked. Suggestions (again, as always) are most welcome.
   
   
10. What do you do with requirements that are incomplete or incomprehensible?
    I send an email saying "I don't understand what you mean. Please read the very small attached book and get back to me."
    
    
    
    Just kidding, of course (at least in most cases. I've been recently tempted to send that exact email, as it happens.)
    
    I just ask them to clarify. If I don't have contact with the customer, I ask the intermediary to clarify or get clarification.
    
    Outside reading: Agile, and hopefully other processes for some compare and contrast.
    
    

I think these are decent answers to start a discussion with. If you're a hiring manager, what do you say? Would you show me the door, or keep me around for a while longer?

It's not quite as hard as Steve Yegge's list of things to know (I'll get to that eventually), but it's a good (and more well-rounded!) list nevertheless.

How would you answer the Requirements questions?

A disclaimer: I've yet to read the relevant book (Lean Software Development: An Agile Toolkit) from the Poppendieck's that brought Lean to software. They may have covered this before.

What my question covers is this: Can we think of an idea that would be repeatable, sell it to customers to fund the project, and then deliver it when it's done? (It should be sold to many customers, as opposed to custom software, which is, for the most part, already developed in that manner.)

In essence, can we pre-sell vaporware?

We already pre-sell all types of software - but that software is (presumably) nearing a releasable state (I've had my doubts about some of it). Can we take it to the next level and sell something which doesn't yet exist?

If such a thing is possible, there are at least three things you'll need to be successful (and I bet there are more):

• A solid reputation for excellence in the domain you're selling to, or a salesperson with such a reputation, and the trust that goes with it.
• A small enough idea such that it can be implemented in a relatively short time-frame. This, I gather, would be related to the industry in which you're selling the software.
• An strong history of delivering products on time.

What do you think? Is it possible? If so, what other qualities do you need to possess to be successful? If not, what makes you skeptical?

What can we do to help them get over this irrational behavior? If they continuously request those trivial changes and never go live, the project has failed. Do you think they will blame themselves, their ideas, and their actions? No, they will blame you, and find someone else to work with next time. So you may have been paid for your time, but it still impacts you negatively.

Don't get me wrong - sometimes there are good reasons to wait to release a product or service. Sometimes, you don't need to DIFN. However, the fear that your customers won't know to look under "output devices" to find a subcategory of "printers" is probably not on that list of reasons. Someone has been using a product to great advantage for many years and you want to "wait until you finish the last bit" to sell it as a whole to others - also probably not on that list. You want the login on the left hand side instead of the right?

After a week of such changes, it's one thing. Six months? GMAFB.

Perhaps you'd have been better off letting your customer's use it to see if they got confused, preferred blue links to red ones, or even happened upon an idea to make the application flow better.

So what does make the "OK to wait"-list? The fear of underwhelming an audience with your unfinished product would, especially if you're get to show them exactly one time. I can't think of much else that does. Can you?

So the point is that you need to get over the fear of success. Stop snatching defeat from the jaws of victory. Let a good thing or two happen. Help your customer's get past their fears.

Changing ourselves to recognize that fear and ignore it is something we can all do. Looking at our customer's excuses to keep the product in the warehouse from a fear-of-success angle might provide a way to relate to them instead of scoffing at their incessant requests for frivolity.

Success is staring you in the face. All you have to do is stick your hand out and embrace hers. Why do you turn and run away?

I'm exploring this space for the first time. Obviously, I have a lot of questions and very few answers. If you've got either of them, let me know in the comments - it's always appreciated.

Preproject Considerations
Most of our business comes through referrals or new projects from existing customers. Out of those, we try only to accept referrals or repeat business from the "good clients," believing their friends will be similarly low maintenance, high value, and most importantly, great to work with.

We have tried the RFP circuit in the past, and recently considered going at it again. However, after a review of our experiences with it, we felt that unless you are the cause of the RFP being initiated, you have a subatomically small chance of being selected for the project (we've been on both ends of that one). Since it typically takes incredible effort to craft a response, it just seems like a waste of hours to pursue.

On the other hand, we are considering creating a default template and using minimal customization to put out for future RFPs, and even then, only considering ones that have a very detailed scope, to minimize our effort on the proposal even further.

We're also trying to move ourselves into the repeatable solutions space - something that really takes the cheap manufacturing ability we have in software - copying bits from one piece of hardware storage to another - and puts it to good use.

Finally, I'm very interested to hear how some of you in the small software business world bring in business. I know we're technically competitors and all, but really, how can you compete with this?

The Software Development Life Cycle
I won't bother you by giving a "phase" by phase analysis here. Part of that is because I'm not sure if we do all the phases, or if we're just so flexible and have such short iterations the phases seem to bleed together. (Nor do I want to spend the time to figure out which category what each thing belongs in.) Depending on the project, it could be either. Instead, I'll bore you with what we do pretty much every time:

At the start of a project, we sit down with client and take requirements. There's nothing fancy here. I'm the coder and I get involved - we've found that it's a ridiculous waste of time to pass my questions through a mediator and wait two weeks to get an answer. Instead, we take some paper or cards and pen, and dry erase markers for the whiteboard. We talk through of what the system should do at a high level, and make notes of it.

We try to list every feature in terms of the users who will perform it and it's reason for existence. If that's unknown, at least we know the feature, even if we don't know who will get to use it or why it's needed. All of this basically gives us our "use cases," without a lot of the formality.

I should also note that, we also do the formal bit if the need is there, or if the client wants to work that way. But those meetings can easily get boring, and when no one wants to be there, it's not an incredibly productive environment. If we're talking about doing the project in Rails or ColdFusion, it often takes me longer to write a use case than it would to implement the feature and show it to the client for feedback, so you can see why it might be more productive to skip the formality in cases that don't require it.

After we get a list of all the features we can think of, I'll get some rough estimates of points (not hours) of each feature to the client, to give them an idea of the relative costs for each feature. If there is a feature which is something fairly unrelated to anything we've had experience with, we give it the maximum score, or change it to an "investigate point cost," which would be the points we'd need to expend to do some research to get a better estimate of relative effort.

Armed with that knowledge, they can then give me a prioritized list of the features they'd like to see by next Friday when I ask them to pick X number of points for us to work on in the next week. Then we'll discuss in more detail those features they've chosen, to get a better idea of exactly what it is they're asking for.

We repeat that each iteration, adjusting the X number of points the client gets to choose based on what was actually accomplished the previous iteration - if there was spare time, they get a few more points. If we didn't finish, those go on the backlog and the client has fewer points to spend. Normally, we don't have the need for face to face meetings after the initial one, but I prefer to have them if we can. We're just not religious about it.

Whiteboards at this meeting are particularly useful, as most ideas can be illustrated quite quickly, have their picture taken, and be erased when no longer needed. Plus, it lets everyone get involved when we start prioritizing. Notecards are also nice as they swap places with each other with incredible ease.

Within each iteration, we start working immediately. Most of the time, we have one week iterations, unless there are a couple of projects going on - then we'll go on two week iterations, alternating between clients. If the project is relatively stable, we might even do daily releases. On top of that, we'll interface with client daily if they are available that frequently, and if there is something to show.

If the project size warrants it, we (or I) track our progress in consuming points on a burndown chart. This would typically be for anything a month or longer. If you'll be mostly done with a project in a week, I don't see the point in coming up with one of these. You can set up a spreadsheet to do all the calculations and graphing for you, and in doing so you can get a good idea of when the project will actually be finished, not just some random date you pull out of the air.



Another thing I try to be adamant about is insisting the client start using the product as soon as it provides some value. This is better for everyone involved. The client can realize ROI sooner and feedback is richer. Without it, the code is not flexed as much. Nor do you get to see what parts work to ease the workload and which go against it as early in the product's life, and that makes changes more difficult. For us, the typical client has been willing to do this, and projects seem to devolve into disaster more readily when they don't.

Finally, every morning we have our daily stand-up meeting. Our company is small enough so that we can talk about company-wide stuff, not just individual projects. Each attendee answers three questions:

1. What did you do yesterday?
2. What are you going to do today?
3. What is holding you back

The meeting is a time-conscious way (15 minutes - you stand so you don't get comfortable) to keep us communicating. Just as importantly, it keeps us accountable to each other, focused on setting goals and getting things done, and removing obstacles that get in our way.

On the code side of things, I try to have unit tests and integration tests for mostly everything. I don't have automated tests for things like games and user interfaces. I haven't seen much detriment from doing it this way, and the tradeoff for learning how to do it doesn't seem worth it at the moment.

I would like to learn how to do it properly and make a more informed decision though. That will likely come when time is not so rare for me. Perhaps when I'm finished with school I'll spend that free time learning the strategies for testing such elements.

Luckily, when I'm working on a ColdFusion project, cfrails is pretty well tested so I get to skip a lot of tests I might otherwise need to write.

By the same token, I don't normally unit test one-off scripts, unless there are obvious test cases I can meet or before doing a final version that would actually change something.

I don't know how to do it in CF, but when I've use continuous integration tools for Java projects it has been helpful. If you have good tests, the CI server will report when someone checks in code that breaks the tests. This means bad code gets checked in less often. If you don't have the tests to back it up, at least you'll feel comfortable knowing the project builds successfully.

For maintenance, we normally don't worry about using a project management tool to track issue. Bugs are fixed as they are reported - show stoppers immediately, less important within the day, and things deemed slight annoyances might take a couple of days. I'd like to formalize our response into an actual policy, though.

Similarly, new requests are typically handled within a couple of days if they are small and I'm not too busy - otherwise I'll give an estimate as to when I can have it done.

With bugs in particular, they are so rare and few in number that I could probably track them in my head. Nevertheless, I mark an email with my "Action Required" tag, and try my best to keep that folder very small. Right now I've overcommitted myself and the folder isn't empty, but there was a time recently that it remained empty on most nights.

In any event, I normally only use project management tools for very large projects or those I inherited for some reason or another.

Summary
If you're a practitioner, you can tell the ideas above are heavily influenced by (when not directly part of) Scrum and Extreme Programming. I wouldn't call what we're doing by either of their names. If you're not familiar with the ideas and they interest you, now you know where to look.

Where would we like to go from here?
One thing that sticks out immediately is client-driven automated testing with Selenium or FIT. I'd also like to work for several months on a team that does it all and does it right, mostly to learn how I might better apply things I've learned, heard of, or yet to be exposed to. What else? That will have to be the subject of another post, as this one's turned into a book.

Thoughts, questions, comments, and criticisms are always welcome below.

I never used to have any sort of process. We might do a little requirements gathering, then code everything up, and show it to the customer a couple of months later. They'd complain about some things and offer more suggestions, then whoever talked to them would try to translate that to me, probably a couple of weeks after they first heard it. I'd implement my understanding of the new requirements or fixes, then we'd show it to the customer and repeat.

It was roughly iterative and incremental, but highly dysfunctional.

I can't recall if it was before or after reading this advice, but it was around the time nevertheless that I started reading and asking questions on several of the agile development mailing lists.

Doing that has given me a much better understanding of how to deliver higher quality, working software on a timely basis. We took a little bit from various methodologies and now have a better idea of when software will be done, and we interface with the customer quite a bit more - and that communication is richer than ever now that I involve myself with them (most of the time, anyway). We're rolling out more things as time goes along and as I learn them.

I'd suggest doing the same, or even picking up the canonical books on different methodologies and reading through several of them. I haven't done the latter quite yet, but it's definitely on my list of things to do. In particular, I want to expose myself to some non-Agile methods, since most of my knowledge comes from the Agile camp.

Without exposing yourself to these ideas, it would be hard to learn something useful from them. And you don't have to succumb to the dogma - Chad mentions (and I agree) that it would be sufficient to take a pragmatic approach - that "the best process to follow is the one that makes your team the most productive and results in the best products." But it is unlikely you will have a "revelationary epiphany" about how to mix and match the pieces that fit your team. You've got to try them out, "and continuously refine them based on real experience."

I don't think it would be a bad idea to hire a coach either (if you can afford one - or maybe you have a friend you can go to for help?), so you've got someone to tell you if you're doing it the wrong way. If you have a successful experiment, you probably did it the right way. But you won't likely know if you could get more out of it. The same is said of doing it the wrong way - you may be discarding an idea that could work wonders for you, if only you'd done it how it was meant to be.

In the end, I like a bit of advice both Venkat and Ron Jeffries have given: You need to learn it by doing it how it was meant to be done. It's hard to pick and choose different practices without having tried them. To quote Ron,

My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?

Do you have any methodological horror stories or success stories? I'd love to hear them!

Update: Did I really spell "dysfunctional" as "disfunctional" ? Yup. So I fixed that and another spelling change.

Scott first explained why asking "which web framework should I use?" is virtually pointless. How do I know what framework you should use? I don't know what you're looking for in it. I don't know what you need it to do. Answering what you should do based on my needs is "outside my realm of expertise." All of them work, so "every framework out there is potentially the 'right one.'"

Instead, you should ask me "what framework do you use" or even better, "why do you use the framework that you do?" Here he actually related it to cell phones, but I'll stick with the web framework theme. In fact, you could replace web framework with

            x, where x ∈ UsableNouns

and it would still make sense.

Choose? I've got too many stinking options!
At this point Scott started to explain analysis paralysis and brought up a new book to put on my to-read list: The Paradox of Choice: Why More Is Less.

He told a story (I believe to be from the book) that succinctly showed what happens when consumers are presented with too many choices: Given 3-5 options for tasting Jellies/Jams, customers ended up buying more of it. However, increasing that to two-dozen left sales at levels lower than having no sampling at all.

We simply become overwhelmed by the number of options available, turn off, and refuse to make a choice at all. That leads us to the Maximizer/Satisficer concept, where the Maximizers are especially prone to analysis because they try to be more prepared when making decisions and never stop analyzing, even after making the choice. On the other hand, satisficers try to narrow their decision-making points down to a reasonable few.

The existence of analysis paralysis doesn't "mean that we should limit the number of frameworks that can be legally created." Instead, we should try to be like the satisficer and "limit out decision criteria to 3-5 important attributes."

So which framework should I use?
Consider "Plain Old HTML." As Scott noted, "Nothing will scale better, nothing is easier to deploy, [and] nothing is better supported across all vendors, servers, platforms, languages..." Even without all that, "it forces you to identify what features you really need." That, according to Scott, is the most important reason to use plain HTML. In any case, make sure you stick to standards so you can switch easily.

But the interesting part for me was not his discussion of web frameworks - it was the books he mentioned while making his points (more to put on the to-read list!). Therefore, I'll focus more on that aspect.

Scott brought up Struts - and while one might use The Wisdom of Crowds to justify its use, you might also notice its complexity is reminiscent of an older era and the leaders of the movement have moved on to other things. It is past Struts 1.x time.

Struts 2 is out now, but it has thus far failed to reach The Tipping Point. On the other hand, Ruby on Rails illustrates the qualities of the tipping point: virally contagious, "dramatic and immediate" effect, not "slow and steady." It shows how "tiny 'tweaks' to a proven model can yield big, disproportionate effects." By introducing the concepts of convention over configuration, scaffolding, and "opinion-oriented software" to the traditional MVC approach, Rails hit the tipping point.

When to adopt new technology
Aside from narrowing your decision points and using the heuristic of the wisdom of crowds, Scott introduced the Gartner Hype Cycle, the O'Reilly Curve, and yet another book to go on my reading list, Crossing the Chasm to help explain the tipping point and give something to consider as to when you might want to adopt a new technology.


Gartner explains the Gartner Hype Cycle well enough, so I'll leave it to you to learn from the source.


The O'Reilly Curve (as near as I can tell) was invented by Doug Kaye of IT Conversations. Basically, the idea is that "publication of an O'Reilly book signals a transition of that technology from 'innovation' to 'early adopter' phase."

Update: Thanks to Doug, you can read a full discussion about the O'Reilly Curve at his blog.

As you can see in the graph above, there are many stages to technology adoption. Although you may want to be an early adopter to increase your chance of success, you can see that you don't achieve return on investment (as an organization) until after there are experienced staff available to work in the new technology.

Before that, you have some lead-time that can bring you competitive advantage.

So when is the best time to move in? If I recall correctly, Scott mentioned the same as Doug Kaye- when O'Reilly publishes a book. That gives you enough resources to be successful, and enough lead-time to be ahead of competitors. Of course, your acceptable level of risk and values will vary, so your choice ultimately comes down to the type of person you are or organization you work in (also explained in Gartner).

As our final heuristic, we can look at the chasm and ask ourselves, "Has the technology crossed it yet?"


Thinking about these things is not only useful from a technology perspective, but from a sales and marketing business perspective for your own products, which is what interests me more about them. (I don't have much experience in those areas, which is why I'm putting these books on my to-read list.) Because of that, I'll remain otherwise silent on the issue, only noting that you needn't look at them from one perspective.

"You know that thing you think is a duck? Well I think it's a rabbit."
Scott said something like that when he began a discussion of paradigm shifts, noting that Rails and Grails are "still fundamentally page-centric MVC frameworks." On the other hand, JSF, Seam, and Tapestry are based on the idea of component-widgets and are much more in line with the Web 2.0 paradigm shift. (The book from this section that goes on my to-read list is The Structure of Scientific Revolutions, which talks about paradigm shifts in science.)

Bringing it all together
You should be convinced that asking what framework you should use is a poor question. You should be asking what other people use and "why?" As Scott reiterated at the end of his presentation, "I can't tell you which filters to apply" when making your decision. But the key is found in "thin-slicing" (from the final book I'll link to today, Blink: The Power of Thinking Without Thinking).

Thin-slicing is the act of "filtering on the few factors that matter" while "ignoring the overwhelming number of others." Sound familiar? It should.

The point is that when making a choice about something, be it technology or otherwise, you need to consider only what is relevant. Pick a few features you need, pick a level of adoption or risk you're willing to handle, and consider shifting paradigms (will the well established still be around?). Ask someone what they use and why they use it. Then, when you've narrowed the field of consideration to something manageable, you can make your choice.

So, what framework I should use?

Working for a tiny consulting company, I get the benefit of being close to all the business decisions, but not in many specialized domains. However, since I made the decision to stop being a "code robot" (Chad's term), I've always taken the opportunity to talk with clients or meet them for lunch to discuss their domains. Even more recently, a couple of us here have taken to reading trade publications related to a product we're building.

Doing so helps you understand why some of those "crazy" requests are made, and what you can do to make them work in the system while still accomplishing the client's goals. And things just seem to work better that way. Nowadays, I'm no longer getting any "that's a nice system, but it's not what I wanted" comments due to keeping myself stuck in a walled garden. Instead, I'm building software customers want and will use. And the purely selfish benefit: I'm adding to my value as an employee or contractor in those domains.

As an aside, last week I was on vacation, so that's why you didn't see this then. I'll try to make up for it and post two this week.

So are you a code monkey? Are you trying to evolve into a code human?

Quite some time ago when I read about what could be done on SL via its economy (several months before I started blogging, if I recall correctly), I thought I'd like to get involved and start a company that developed for it. Of course, I've still yet to act on it, but given my prior predisposition to wanting to do that sort of thing, when Matt mentioned two of his primary reasons for doing it - wanting his brand to have a progressive image and getting a good deal on the price by being an early adopter - I was easily convinced to change my position. He also talked a bit about their strategy, which I won't go into here, but it seemed more solid after listening to him speak than after simply reading the case.

It's still too early to tell if this will be a flop - for STA, their site is still under development, and in general, it is still new anyway - but there are some signs pointing to success. For example, companies who have developed their own islands include Toyota, Mazda, Starwood Hotels, IBM, Circuit City, Sears, Dell, Sun Microsystems, MTV, Adidas, American Apparel, PA Consulting, and Major League Baseball. Not-for-profits include the American Cancer Society and "a number of universities" (both lists from the case study, which isn't public to my knowledge, so I don't want to release it before it is completed, much less violate the copyright by posting it myself).

CNN Money also published a piece that details "why tech leaders think Second Life could be a gold mine." From that article:

The company's backers include some of the world's smartest, richest, and most successful tech entrepreneurs. The chairman and first big outside investor is Mitch Kapor, creator of Lotus 1-2-3, the spreadsheet application that helped begin the PC software revolution. Other investors include eBay founder Pierre Omidyar, Amazon CEO Jeff Bezos, and Microsoft chief technology architect (and inventor of Lotus Notes) Ray Ozzie - each credited with a seminal networked product of our age.

Those are some real heavyweights.

And what interests me most about SL is its economy. Aside from the fact that you could use Euros and deposit them to convert them to Linden dollars (the currency of SL) and then go to the United States and withdraw them as US Dollars, you also see people buying genitalia, hair, shirts, and other items for their virtual selves. It's not a far leap to see that converted to selling real life items. You can check out some economic stats from Second Life here. In particular interest to my case is that this month (March 2007) has seen about double the number of islands sold as last month, with half-again as much land auctioned off. They seem to be gaining new members at a rate of 20 thousand per day, though it seems only a little over a million residents are active participants, with 20-30 thousand on at any given time. In particular, they have just about doubled from 2.6 million users to 5+ million since January. Perhaps the most interesting is that at the time of this writing, over $1.5 million (US) had been spent in the world in the last 24 hours. That's up from $600 thousand per day back in January.

I've focused on Second Life here because that is the one I'm most familiar with, but I want to ask the general question: do you think the future of online marketing can be found in 3D virtual worlds? Why or why not?

• IT Resources Barrier: This barrier is given by IT assets and capabilities. How flexible is your IT infrastructure? Better than your competitors? How good are your technical people's skills, including management? How good is the relationship between business users and IS developers?
  
  
• Complementary Resources Barrier: They use the example of Harrah's using its "national network of casinos to capture drive-in traffic and foster cross-selling" between locations as a perfect example. They also note that these complementary resources need not be considered assets, and could even be liabilities, which, when teamed with the right project could turn into assets.
  
  
• IT project barrier: This includes the characteristics of the new technology - how visible, complex, and unique it is. Further, it adds the implementation' complexity and process change. Can your competitors readily see your new technology? How complex is it to build? Is it just off-the-shelf software that a competitor could buy as well, or is it proprietary? How complex is it to implement (is it as simple as Word, or is it a complete ERP system), and how much will your daily business processes need to evolve in the implementation of change?
  
  
• Preemption Barrier: Whereas for the most part we can control the first three barriers within our own organization, or more importantly, a competitor theirs, this is less easy to control, but should be easy enough to predict (I don't think they say that, but based on the description, I think it would be). The idea here "focuses on the question of whether, even after successful imitation has occurred, the leader’s position of competitive advantage can be threatened." What are the switching costs for users of your application? Are they high enough to prevent them from leaving if a competitor was able to imitate your system? It also includes the structure of the value system: do they need another provider of this service (relationship exclusivity)? The authors use the example that you typically have only one mutual fund investment provider. Finally, is the link you are serving with the project in the value chain concentrated enough that you can capture most of the market and "lock-out" your competitors?

I couldn't find the paper online (for free), but if you are interested, you can find it at MIS Quarterly.